什么是微服务架构
微服务架构的核心思想是把一个大型单体应用拆分成多个小型、独立的服务。每个服务运行在自己的进程中，服务之间通过轻量级机制（通常是 HTTP RESTful API 或消息队列）进行通信。
用一个简单的例子来说明：假设你有一个 Node.js 单体应用，里面包含鉴权模块、数据库模块、业务模块一、业务模块二。在微服务架构下，鉴权服务会被单独拆出来作为一个独立进程部署在独立的容器中，数据库访问也独立为一个服务，每个业务模块各自独立运行。不同的服务之间通过 RESTful 接口互相调用，最终形成一个完整的系统。
单体应用 vs 微服务
| 维度 | 单体应用 | 微服务架构 |
|---|---|---|
| 部署方式 | 整体打包、整体部署 | 各服务独立部署 |
| 更新影响 | 修改任何功能都需重新部署整体 | 更新某个服务不影响其他服务 |
| 技术栈 | 统一技术栈 | 每个服务可以独立选择技术栈 |
| 运维复杂度 | 较低 | 较高，需要管理多个服务 |
| 扩展方式 | 整体水平扩展 | 按需对特定服务独立扩展 |
| 故障影响 | 一个模块崩溃可能导致整体不可用 | 单个服务故障不影响其他服务 |
微服务的滚动更新
微服务在更新时并不会让服务中断。以鉴权服务为例，运维层面（通常是 K8s）会同时运行旧版本和新版本两个实例，前面有一层负载均衡（如 Nginx 或 K8s Ingress）。等新版本实例启动并健康检查通过后，才会移除旧版本实例。整个过程对用户无感知。
用户请求 → 负载均衡 → [鉴权服务-old, 鉴权服务-new]
↑ 新实例启动完成后，移除旧实例
text
在 K8s 中，这种滚动更新是内置支持的，开发者只需关注服务本身的运行状态和更新逻辑，底层的流量管理、日志监控等可以交给 K8s 运维平台处理。
微服务架构的好处与弊端
根据《微服务架构设计模式》（作者 Chris Richardson）第 15 页的总结：
好处
- 服务独立部署和扩展 -- 每个微服务可以独立部署，不需要协调其他服务的部署周期。高负载的服务可以单独扩容，不需要浪费资源给低负载的服务。
- 团队自治 -- 不同的团队可以负责不同的微服务，各自选择合适的技术栈和开发节奏。
- 故障隔离 -- 单个服务的故障不会直接导致整个系统不可用。
- 技术异构性 -- 不同服务可以根据需要选择不同的编程语言、数据库、框架。
弊端
- 服务拆分是一项挑战 -- 如何确定服务的边界是最困难的问题之一。拆得太细会增加通信开销和运维成本，拆得太粗又失去了微服务的优势。
- 分布式系统的复杂性 -- 网络延迟、数据一致性、分布式事务等问题显著增加。
- 测试和部署更困难 -- 端到端测试需要启动多个服务，部署流程更加复杂。
- 需要协调更多的开发团队 -- 服务间的接口契约需要团队间协商维护。
微服务的拆分策略
服务的拆分是微服务架构中最核心的决策之一。以下是几种常见的拆分维度：
按业务功能拆分
将系统按独立的业务领域进行拆分。以管理后台为例：
- 内容服务 -- 文章、课程的增删改查
- 消息服务 -- 站内信、通知推送
- 统计服务 -- 数据分析、报表生成
- 订单服务 -- 支付、退款、订单管理
每个服务拥有独立的数据库，对外提供清晰的 API。
按功能模块拆分
将系统按技术功能进行拆分：
- 审计服务 -- 操作日志记录
- 模板服务 -- 页面模板管理
- 数据库管理服务 -- 数据备份、迁移
按资源特征拆分
根据资源的访问模式和负载特征来拆分：
| 资源特征 | 示例 | 拆分理由 |
|---|---|---|
| 高频访问 | 鉴权服务 | 需要独立扩容应对高并发 |
| 低频访问 | 后台管理 | 资源消耗少，可与其他服务共享资源 |
| IO 密集 | 文件上传、第三方接口调用 | 独立部署避免阻塞其他服务 |
| 计算密集 | 图片压缩、视频处理 | 需要高 CPU 资源，独立部署避免影响其他服务 |
微服务的应用场景
微服务并不适合所有场景。以下是适合和不适合使用微服务的典型场景：
适合使用微服务的场景
- 大型复杂系统 -- 系统模块多、业务逻辑复杂，团队需要并行开发
- 快速迭代升级 -- 业务在不断快速成长，需要频繁发布新功能
- 高并发高可用 -- 系统需要承受大量并发请求，且不能容忍单点故障
- 多团队协作 -- 多个开发团队同时工作在同一个系统上
不适合使用微服务的场景
- 小型项目或初创期产品 -- 业务边界不清晰，团队规模小
- 低并发系统 -- 用户量不大，单体应用完全能够满足需求
- 团队缺乏微服务经验 -- 运维和治理成本可能会压垮团队
选择建议
对于大多数中小型项目，从单体应用开始是更明智的选择。当业务复杂度和团队规模增长到一定程度时，再逐步拆分为微服务。过早引入微服务架构会导致不必要的复杂性。
微服务与分布式系统的关系
微服务和分布式系统经常被放在一起讨论，但它们有不同的侧重点：
- 分布式系统强调的是部署层面 -- 将系统部署在多台机器上，通过负载均衡分发流量，目标是提高性能、可扩展性和容错性
- 微服务强调的是架构层面 -- 按业务能力拆分独立服务，每个服务可以独立开发、部署和扩展
一个简洁的概括：分布式分散的是压力，微服务分散的是能力。在实际生产中，微服务通常和分布式部署配合使用 -- 每个微服务可能会部署多个实例在多台机器上，前面通过负载均衡分发请求。
↑